x86/VT-x: Don't activate VMCS Shadowing outside of nested vmx mode
authorAndrew Cooper <andrew.cooper3@citrix.com>
Fri, 1 Feb 2019 10:31:28 +0000 (11:31 +0100)
committerJan Beulich <jbeulich@suse.com>
Fri, 1 Feb 2019 10:31:28 +0000 (11:31 +0100)
commit63d71138a4d3521cf42ff28b0dd3e79b82d79230
tree2529716f2b8b3b6897c6ba2d9db223bfcc4250a5
parentaf25f52a06a82789acf91fd98f71c8563919ab0b
x86/VT-x: Don't activate VMCS Shadowing outside of nested vmx mode

By default on capable hardware, SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is
activated unilaterally.  The VMCS Link pointer is initialised to ~0, but the
VMREAD/VMWRITE bitmap pointers are not.

This causes the 16bit IVT and Bios Data Area get interpreted as the read/write
permission bitmap for guests which blindly execute VMREAD/VMWRITE
instructions.

This is not a security issue because the VMCS Link pointer being ~0 causes
VMREAD/VMWRITE to complete with VMFailInvalid (rather than modifying a
potential shadow VMCS), and the contents of MFN 0 has already been determined
not to contain any interesting data because of L1TF's ability to read that 4k
frame.

Leave VMCS Shadowing disabled by default, and toggle it in
nvmx_{set,clear}_vmcs_pointer().  This isn't the most efficient course of
action, but it is the most simple way of leaving nested-virt working as it did
before.

While editing construct_vmcs(), collect all default secondary_exec_control
modifications together.  The disabling of PML is latently buggy because it
happens after secondary_exec_control are written into the VMCS, although there
is an unconditional update later which writes the correct value into hardware.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 75ce36eb72cb93e8a3c9f60fd5e697067921d712
master date: 2018-12-10 16:24:08 +0000
xen/arch/x86/hvm/vmx/vmcs.c
xen/arch/x86/hvm/vmx/vvmx.c